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Apr 24, 2001 



DOCUMENT- IDENTIFIER: US 6223222 Bl 

TITLE: Method and system for providing quality-of-service in a data-over-cable 
system using configuration protocol messaging 

Detailed Description Text (152): 

A system for a preferred embodiment of the present invention includes a quality-of- 
service server (e.g., QoS server 332), for determining whether a first network 
device has enough available bandwidth to establish a connection to a second network 
device with a specific quality-of-service requested by the second network device. 
The quality-of-service server provides support for class-of-service, quality-of- 
service and other parameters. The system also includes multiple quality-of-service 
identifiers, for identifying a transmission bandwidth required for a specific 
quality-of-service requested by a second network device, wherein a value for a 
quality-of-service identifier is determined by the quality-of-service bandwidth 
requested by class-of-service, quality-of-service and other parameters. In a 
preferred embodiment of the present invention, the quality-of-service server is QoS 
server 332, the first network device is CMTS 12 and the second network device is CM 
16. However, the present invention is not limited to these network devices and 
other network devices could also be used. 

Detailed Description Text (156) : 

FIG. 23 is a block diagram illustrating a data-over-cable system 400 with a QoS 
server 402 that is also a DHCP 66 server. QoS server 402 determines if CMTS 12 has 
available bandwidth for network devices such as CM 16 for quality-of-service 
requests in data-over-cable system 400 using DHCP 66 messaging. Bandwidth is 
allocated for class-of-service, quality-of-service and other parameters and is 
hereinafter collectively referred to as "quality-of-service" bandwidth for the sake 
of simplicity. FIG. 23 is similar to FIG. 18 except DHCP server 160 includes 
quality-of-service capabilities and is illustrated as QoS server 402. In a 
preferred embodiment of the present invention, DHCP server 160 is integral to QoS 
server 402. In such an embodiment, QoS server 402 is used to provide DHCP 66 
f inctionality as described above as well as quality-of-service functionality. In 
another embodiment of the present invention, quality-of-service server 402 is a 
separate server with DHCP 66 and quality-of-service capabilities (e.g., server 332 
FIG. 18) . In such an embodiment, DHCP server 160 is used for DHCP 66 messaging and 
QoS server 402 provides quality-of-service capabilities with DHCP 66 messaging. 

Detailed Description Text (178) : 

A system for a preferred embodiment of the present invention includes a quality-of- 
service server (e.g., QoS 402), for determining whether a first network device has 
enough available bandwidth to establish a connection to a second network device 
with a specific quality-of-service requested by the second network device. The 
quality-of-service server provides support for class-of-service, quality-of-service 
and other parameters with DHCP 66 messaging. 



Current US Original Classification (1) : 
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DOCUMENT- IDENTIFIER: US 5724513 A 

TITLE: Traffic shaping system for asynchronous transfer mode networks 



Brief Summary Text (7 ) : 

The network initially uses the QoS parameters in the connection request for 
admission control. When a connection request is made, the network determines 
whether sufficient resources (transmission bandwidth, buffers, or other) exist to 
allow the connection to be established with the requested parameters, while not 
impacting the QoS of already established connections. If there are insufficient 
resources to support the requested QoS, the connection request is rejected, and the 
station may repeat the request with lower QoS parameters. 

Detailed Description Text (7) : 

The network responds to the connection request issued by the user on End Station 1 
10 by either creating the requested VC, or denying the request. In determining 
whether a requested VC can be established between End Station 1 10 and End Station 
2 25, the network determines whether there are sufficient resources (for example 
transmission bandwidth and buffers) across the network from source to destination, 
for example in Intermediate Station 1 15 and Intermediate Station 2 20, to allow 
the requested VC to be set up with the requested QoS parameters, while not 
impacting the QoS of already established VCs . If there are not sufficient resources 
to do so, the connection request is rejected, and the user on End Station 1 10 may 
repeat the request with lower QoS parameters. 

Current US Original Classification (1) : 
709/234 

Current US Cross Reference Classification (1) : 
709/238 
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DOCUMENT- IDENTIFIER : US 6055571 A 

TITLE: Computer network with microeconomic flow control 



Detailed Description Text (40) : 

In FIG. 15, the plotted curve is called the softness profile and is derived by 
setting B at a value shortly to be described; by setting A at about 1.1 times B; 
and by setting C at about 0.7 times B. In FIG. 15, the horizontal axis is the 
bandwidth ratio. The bandwidth ratio is the ratio of "purchased" bandwidth to 
"desired" bandwidth. If the bandwidth ratio is 1, it means the user can afford the 
bandwidth he desires and thus the satisfaction is total (indicated as 5 in the 
vertical axis, which represents a satisfaction index) . The value B is the 
percentage of the desired bandwidth corresponding to a level of performance which, 
although not to the level desired, provides good quality of service to the user for 
the given application. In other words, to maintain good (i.e., acceptably degraded) 
performance, the application needs to purchase at least B % of the desired 
bandwidth. Table 1 shows an example of how B may vary according to the different 
categories of applications. Thus, once the NB gets the price, it uses the 
applications particular QoS profile to determine how much bandwidth it should ask 
the network for. The exact form of the softness profile depends on the application. 



Current US Original Classification ( 1 ) : 
709/224 



heb bgeeef e eg 



Record List Display ^ X A Page 1 of 3 



Hit List 



Clear 


Generate Collection 


Print 


Fwd Refs 


Bkwd Refs 




Generate OACS 





Search ResultijJl£Cord(s) 1 through 1 of 1 returned. 



i^D\ 1 . Document ID: US 6223222 Bl. 

/l8: yntry 1 of 1 



File: USPT 



Apr 24, 2001 



DOCUMENT-IDENTIFIER: US 6223222 Bl 

TITLE: Method and system for providing quality-of-service in a data-over-cable 
system using configuration protocol messaging 



Brief Summary Text (13) : 

As is known in the art, class-of-service provides a reliable (e.g., error free, in 
sequence, with no loss of duplication) transport facility independent of the 
quality-of-service. Class-of-service parameters include maximum downstream data 
rates, maximum upstream data rates, upstream channel priority, guaranteed minimum 
data rates, guaranteed maximum data rate and other parameters. Quality-of-service 
collectively specifies the performance of a network service that a device expects 
on a network. Quality-of-service parameters include transit delay expected to 
deliver data to a specific destination, the level of protection from unauthorized 
monitoring or modification of data, cost for delivery of data, expected residual 
error probability, the relative priority associated with the data and other 
parameters . 

Detailed Description Text (22) : 

CM 16 forwards IP 54 datagrams destined to an IP 54 unicast address across cable 
network 14 or PSTN 22. Some routers have security features intended to filter out 
invalid users who alter or masquerade packets as if sent from a valid user. Since 
routing policy is under the control of network operators, such filtering is a 
vendor specific implementation. For example, dedicated interfaces (i.e., Frame 
Relay) may exist between TRAC 24 and CMTS 12 which preclude filtering, or various 
forms of virtual tunneling and reverse virtual tunneling could be used to virtually 
source upstream packets from CM 16. For more information on virtual tunneling see 
Level 2 Tunneling Protocol ("L2TP") or Point-to-Point Tunneling Protocol ("PPTP") 
in IETF draft documents incorporated herein by reference by Kory Hamzeh, et . al 
(IETF draft documents are precursors to IETF RFCs and are works in progress) . 

Detailed Description Text (23) : 

CM 16 also forwards IP 54 datagrams destined to an IP 54 multicast address across 
cable network 14 or PSTN 22. CM 16 is configurable to keep IP 54 multicast routing 
tables and to use group membership protocols. CM 16 is also capable of IP 54 
tunneling upstream through the telephony path. A CM 16 that wants to send a 
multicast packet across a virtual tunnel will prepend another IP 54 header, set the 
destination address in the new header to be the unicast address of CMTS 12 at the 
other end of the tunnel, and set the IP 54 protocol field to be four, which means 
the next protocol is IP 54. 

Detailed Description Text (41) : 

The virtual connection includes receiving data on the first network host interface 
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on the first^ network from the third network and sending the data over the 
downstream ^connection to the first network device. The first network device sends 
data responses back to the third network over the upstream connection to the second 
network, which forwards the data to the appropriate destination on the third 
network. 

Detailed Description Text (127) : 

QoS parameters include transit delay expected to deliver data to a specific 
destination, the level of protection from unauthorized monitoring or modification 
of data, cost for delivery of data, expected residual error probability, the 
relative priority associated with the data and other parameters. 

Detailed Description Text (140) : 

FIG. 20 is flow diagram illustrating a method 352 for providing quality-of-service 
to a cable modem. At step 354, QoS server 332 receives a request from CMTS 12 to 
establish a connection between CMTS 12 and CM 16 with a specific quality-of-service 
requested by CM 16 (e.g., for CoS, QoS and other parameters in Tables 10-20). At 
step 356, QoS server 332 determines whether CMTS 12 has enough available bandwidth 
to establish the connection to CM 16 with the specific quality-of-service requested 
by CM 16. If CMTS 12 has enough bandwidth (e.g., for CoS, QoS and other parameters 
in tables 10-20) to establish the connection to CM 16 with the specific quality-of- 
service requested by CM 16, a bandwidth required for the specific quality-of- 
service requested by CM 16 is subtracted from an available bandwidth for CMTS 12 at 
step 358. At step 360, a quality-of-service identifier is assigned to the specific 
quality-of-service bandwidth requested by CM 16. The assigned quality-of-service 
identifier is saved on QoS server at step 362. At step 364, The assigned quality- 
of-service identifier source identifier is sent to CMTS 12 indicating that CMTS 12 
has enough bandwidth to allow the connection with the specific quality-of-service 
requested by CM 16. If CMTS 12 does not have enough available bandwidth to 
establish the connection to CM 16 with the specific quality-of-service requested by 
CM 16 at step 340, a rejection is sent to CMTS 12 at step 365. 

Detailed Description Paragraph Table (3) : 

TABLE 3 1. An IP 54 datagram from data network 28 destined for CM 16 arrives on 
CMTS-NSI 32 and enters CMTS 12. 2. CMTS 12 encodes the IP 54 datagram in a cable 
data frame, passes it to MAC 44 and transmits it "downstream" to RF interface 40 on 
CM 16 via cable network 14. 3. CM 16 recognizes the encoded IP 54 datagram in MAC 
layer 44 received via RF interface 40. 4. CM 16 responds to the cable data frame 
and encapsulates a response IP 54 datagram in a PPP 50 frame and transmits it 
"upstream" with modem interface 48 via PSTN 22 to TRAC 24. 5. TRAC 24 decodes the 
IP 54 datagram and forwards it via TRAC-NSI 30 to a destination on data network 28. 



Detailed Description Paragraph Table (16) : 

TABLE 16 Type/Subtype Length Description of Value Default Value Bx N Service 
Identifier Header B0 1 Service Identifier Type 0 Bl 1 Number of Service 1 
Identifier's (SIDs) to be given with this definition B2 4 Flow Identifier for 0 
SIDs B3 4 CoS for SIDs 0 B4 4 Source IP 54 address CM's IP 54 address B5 4 Source 
IP 54 address 255.255.255.255 mask B6 4 Destination IP 54 255.255.255.255 address 
B7 4 Destination IP 54 255.255.255.255 address mask B8 1 IP Protocol Type 256 B9 4 
Source Port (Start) 0 B10 4 Source Port (End) 65,535 Bll 4 Destination Port 0 
(Start) B12 4 Destination Port (End) 65,535 B13 1 Precedence and TOS 0 B14 1 
Precedence and TOS 255 Mask B15 N Multicast group Null string"" definition B16 4 
Protocol Type Oxffffffff B17-B127 N Reserved B128-B255 N Vendor Specific 
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□ 1. Document ID: 

L2: Entry 1 of 2 



File: USPT 



Apr 24, 2001 



DOCUMENT-IDENTIFIER: US 6223222 Bl 

TITLE: Method and system for providing quality-of -service in a data-over-cable 
system using configuration protocol messaging 



Detailed Description Text (124) : 

FIG. 18 is a block diagram illustrating data-over-cable system 330 used for a 
preferred embodiment of the present invention. Data-over-cable system 330 is 
similar to the data over cable system illustrated in FIG. 8. However, FIG. 18 
illustrates a QoS server 332 used to determine whether CMTS 12 has available 
bandwidth to provide a specific quality-of-service request to a CM 16. A quality- 
of-service bandwidth request includes bandwidth allocated for CoS, QoS and other 
related parameters and is hereinafter called "quality-of-service " bandwidth 
request". QoS server 332 handles CoS, QoS and other related parameters and is 
hereinafter called a " QoS server" for the sake of simplicity. QoS server 332 
maintains multiple q uality-of-service identifiers allocated with a database 334 
for CoS and other QoS designations. The multiple quality-of-service identifiers are 
an indication of CoS, QoS and other related parameters requested by CM 16 and are 
collectively called "quality-of-service identifiers" for the sake of simplicity. 
FIG. 18 illustrates QoS server 332 separate from CMTS 12 in TRTS 26. However QoS 
server 332 may also be integral to CMTS 12 (e.g., as a dedicated QoS process 
running on CMTS 12 or integrated into DHCP 66 server 160) . 

Detailed Description Text (138) : 

FIG. 19 is a flow diagram illustrating a method 336 for providing quality of 
service for a network device in a data over-cable-system. Method 336 includes 
receiving a request on a first network device from a second network device to 
establish a connection between the second network device and a third network device 
with a specific quality-of-service at step 338. The quality-of-service request 
includes bandwidth for CoS, QoS and other parameters. The first network device 
determines whether the second network device has enough available bandwidth to 
establish the connection to the third network device with the specific quality-of- 
service requested at step 340. The bandwidth determination includes a bandwidth 
determination required for CoS, QoS and other parameters. If the first network 
device has enough bandwidth to establish the connection to the third network device 
with the specific quality-of-service at step 340, a bandwidth required for the 
specific quality-of-service is subtracted from an available bandwidth for the 
second network device at step 342. At step 344, a quality-of-service identifier is 
assigned to the specific quality-of-service bandwidth requested. The quality-of- 
service identifier is assigned based on bandwidth required CoS, QoS and other 
parameters. The assigned quality-of-service identifier is saved on the first 
network device at step 346. The assigned quality-of-service identifier is sent to 
the second network device indicating the second network device has enough bandwidth 
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to allow the., connection with the specific quality-of-service requested at step 348. 
If the first network device does not have enough available bandwidth to establish 
the connection to the third network device with the specific quality-of-service 
requested by the third network device at step 340, a rejection is sent to the first 
network device at step 350. 

Detailed Description Text (140) : 

FIG. 20 is flow diagram illustrating a method 352 for providing quality-of-service 
to a cable modem. At step 354, QoS server 332 receives a request from CMTS 12 to 
establish a connection between CMTS 12 and CM 16 with a specific quality-of-service 
requested by CM 16 (e.g., for CoS, QoS and other parameters in Tables 10-20). At 
step 356, QoS server 332 determines whether CMTS 12 has enough available bandwidth 
to establish the connection to CM 16 with the specific quality-of-service requested 
by CM 16. If CMTS 12 has enough bandwidth (e.g., for CoS, QoS and other parameters 
in tables 10-20) to establish the connection to CM 16 with the specific quality-of- 
service requested by CM 16, a bandwidth required for the specific quality-of- 
service requested by CM 16 is subtracted from an available bandwidth for CMTS 12 at 
step 358. At step 360, a quality-of-service identifier is assigned to the specific 
quality-of-service bandwidth requested by CM 16. The assigned quality-of-service 
identifier is saved on QoS server at step 362. At step 364, The assigned quality- 
of-service identifier source identifier is sent to CMTS 12 indicating that CMTS 12 
has enough bandwidth to allow the connection with the specific quality-of-service 
requested by CM 16. If CMTS 12 does not have enough available bandwidth to 
establish the connection to CM 16 with the specific quality-of-service requested by 
CM 16 at step 340, a rejection is sent to CMTS 12 at step 365. 

Detailed Description Text (148) : 

In one embodiment of the present invention, QoS server determines bandwidth 
available on CMTS 12 with quality-of-service identifiers assigned to CMTS 12 and 
subtracting QoS bandwidth from an available bandwidth . For example, if CMTS 12 has 
a total available bandwidth of 1000 Mbps and has allocated ten CoS-1 quality-of- 
service requests at 12 Mbps each, and 5 CoS-2 quality-of-service requests at 6 Mbps 
each, then CMTS 12 has 850 Mbps of available bandwidth remaining (1000 Mbps- 
(10*12+5*6)Mbps=850 Mbps). 

Detailed Description Text (150) : 

A preferred embodiment of the present invention is illustrated with interactions 
between CM 16, CMTS 12 and QoS 332. However, the present invention can also be 
practiced by making QoS requests directly to QoS server 332 directly from CM 16. In 
such an embodiment, CM 16 sends a quality-of-service identifier returned from QoS 
server 332 in a registration message to CMTS 12. CMTS 12 allocates a connection 
with a specific quality of service requested by CM 16 when a quality-of-service 
identifier is detected in the registration message, indicating that CMTS 12 has 
available bandwidth for the specific quality-of-service request . 

Detailed Description Text (151) : 

A preferred embodiment of the present invention is described for one CMTS 12 as is 
illustrated in FIG. 18. However, QoS server 332 can also be used to handle and 
balance CoS, QoS and other requests among multiple CMTS 12 (not illustrated in FIG. 
18) . For example, if CM 16 makes a connection request with a requested quality-of- 
service for a first CMTS 12, and first CMTS 12 does not have the available 
bandwidth, QoS server 332 directs a second CMTS with available bandwidth to respond 
to the connection request from CM 16. 

Detailed Description Text (152) : 

A system for a preferred embodiment of the present invention includes a quality-of- 
service server (e.g., QoS server 332), for determining whether a first network 
device has enough available bandwidth to establish a connection to a second network 
device with a specific quality-of-service requested by the second network device. 
The quality-of-service server provides support for class-of-service, quality-of- 
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service and other parameters. The system also includes multiple quality-of-service 
identifiers, for identifying a transmission bandwidth required for a specific 
quality-of-service requested by a second network device, wherein a value for a 
quality-of-service identifier is determined by the quality-of-service bandwidth 
requested by class-of-service, quality-of-service and other parameters. In a 
preferred embodiment of the present invention, the quality-of-service server is QoS 
server 332, the first network device is CMTS 12 and the second network device is CM 
16. However, the present invention is not limited to these network devices and 
other network devices could also be used. 

Detailed Description Text (156) : 

FIG. 23 is a block diagram illustrating a data-over-cable system 400 with a QoS 
server 402 that is also a DHCP 66 server. QoS server 402 determines if CMTS 12 has 
available bandwidth for network devices such as CM 16 for quality-of-service 
requests in data-over-cable system 400 using DHCP 66 messaging. Bandwidth is 
allocated for class-of-service, quality-of-service and other parameters and is 
hereinafter collectively referred to as "quality-of-service" bandwidth for the sake 
of simplicity. FIG. 23 is similar to FIG. 18 except DHCP server 160 includes 
quality-of-service capabilities and is illustrated as QoS server 402. In a 
preferred embodiment of the present invention, DHCP server 160 is integral to QoS 
server 402. In such an embodiment, QoS server 402 is used to provide DHCP 66 
finctionality as described above as well as quality-of-service functionality. In 
another embodiment of the present invention, quality-of-service server 402 is a 
separate server with DHCP 66 and quality-of-service capabilities (e.g., server 332 
FIG. 18) . In such an embodiment, DHCP server 160 is used for DHCP 66 messaging and 
QoS server 402 provides quality-of-service capabilities with DHCP 66 messaging. 

Detailed Description Text (161) : 

FIG. 25 is a flow diagram illustrating a method 414 for determining quality-of- 
service. At step 416, a DHCP 66 discover message is sent from CMTS 12 to QoS server 
402. The DHCP 66 discover message includes a request to determine if CMTS 12 has 
enough available bandwidth to create a connection to CM 16 with a specific quality- 
of-service requested by CM 16. At step 418, a DHCP 66 offer message is received on 
CMTS 12 from QoS server 402 in response to the DHCP 66 discover message. The DHCP 
66 offer message is an offer to reserve bandwidth for CMTS 12 for the specific 
quality-of-service requested by CM 16. The offer message is sent by QoS server 402 
using method 352 (FIG. 20) if CMTS 12 has enough available bandwidth to provide a 
connection to CM 16 with the specific quality-of-service requested . The DHCP 66 
offer message includes a quality-of-service identifier for the specific quality-of- 
service requested in DHCP 66 giaddr-field 130 (FIG. 6) . If CMTS 12 does not have 
enough available bandwidth to provide a connection for the specific quality-of- 
service requested by CM 16, QoS server 402 sends a DHCP 66 negative acknowledgment 
message (i.e., DHCP_NACK) . The DHCP 66 negative acknowledgment message indicates no 
bandwidth is available on CMTS 12 to provide the specific quality-of-service 
request . 

Detailed Description Text (167): 

FIG. 27 is a block diagram illustrating a message flow 428 for quality-of-service 
requests from CM 16. CM 16 executes the steps of method 414 (FIG. 25) using the 
same DHCP 66 messages as was described for CMTS 12. CM 16 sends a DHCP 66 discover 
message 4 30 to QoS server 4 02 to determine if CMTS 12 has enough available 
bandwidth to provide the desired quality-of-service connection requested by CM 16. 
CM 16 receives a DHCP 66 offer message 432 with a hashed quality-of-service 
identifier in a DHCP 66 giaddr-field 130 from QoS server 402 via a downstream 
channel from CMTS 12. CM 16 sends a DHCP request message 434 to QoS server 402 with 
the hashed quality-of-service identifier obtained the DHCP 66 offer message in a 
DHCP 66 giaddr-field 130. DHCP 66 request message 434 with the hashed quality-of- 
service identifier indicates that CM 16 desires to allocate bandwidth on CMTS 12 
for the quality-of-service connection requested by CM 16. CM 16 receives a DHCP 66 
acknowledgment message 436 from QoS server 402 including the hashed quality-of- 
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service identifier in DHCP 66 giaddr- field 130, and indicating that bandwidth for 
the quality-of-service connection requested by CM 16 has been allocated from 
available bandwidth on CMTS 12. 

Detailed Description Text (178) : 

A system for a preferred embodiment of the present invention includes a quality-of- 
service server (e.g., QoS 402), for determining whether a first network device has 
enough available bandwidth to establish a connection to a second network device 
with a specific quality-of-service requested by the second network device. The 
quality-of-service server provides support for class-of-service, quality-of-service 
and other parameters with DHCP 66 messaging. 
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□ 2. Document ID: US 6055571 A 

L2: Entry 2 of 2 



File: USPT 



Apr 25, 2000 



DOCUMENT-IDENTIFIER: US 6055571 A 

TITLE: Computer network with microeconomic flow control 



Detailed Description Text (76) : 

This technique requires signaling to allocate resources. Once a user wishes to (re) 
negotiate for more resources they must send a request to the switches in the route. 
Each switch reads the request and determines the amount of bandwidth it can 
allocate. Allocation is performed on a first come first served basis. If the switch 
is unable to allocate the requested amount, it changes the request to its available 
amount. The new request is then forwarded to the next switch, where the process is 
repeated. The last switch then forwards the request back to the user. The result is 
an allocation which is the minimum amount available in the route. Once the message 
has reached the NB, it must decide if the allocated amount is sufficient using the 
QoS profile given in FIG. 5. If so, it will start sending at the allocated value. 
Note this allocation process requires at least a round trip propagation delay 
before a higher rate can be sent. If the user wishes to use less resources, it can 
do so immediately but must also notify the switches in the route. This is a 
reactive strategy, since the user does not scale back until the network cannot 
support their demands. 
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File: USPT 



Mar 5, 1996 



DOCUMENT-IDENTIFIER: US 5497504 A 

TITLE: System and method for connection control in mobile communications 



Brief Summary Text (4) : 

In recent years, the popularity of mobile communications has increased immensely 
and is expected to grow in the near future to the point where existing systems will 
be unable to support the demand for such communications. A major problem facing the 
future of mobile communications systems is the scarcity of available bandwidth in a 
wireless network for the mobile user's transmission to a fixed network. 

Brief Summary Text (7) : 

Due to the limited bandwidth available for the wireless transmissions of mobile 
users 1 calls, each cell can handle only a limited number of calls. Overload 
conditions occur when the communication needs of wireless terminals populating a 
small area exceed the total capacity of all access points within their reach. This 
situation is referred to as a "radio congestion state." Such a state may be 
encountered during a hand-off, resulting in connection dropping, long delays, 
and/or packet losses. 

Detailed Description Text (16) : 

Class II connections encompass data connections which support applications 
requiring reliable transport. Calls utilizing a standard transmission control 
protocol (TCP) typify such connections. In contrast to class I, class II 
connections may be "put on hold" when a radio congestion state is encountered. 
Relying on the transport protocol of the packets for example, the end-to-end 
connection control entities detect any congestion, and reduce or even stop the flow 
of the packets when such congestion occurs. As a result, class II connections are 
more susceptible to delays (or even packet losses) in a congestion state than under 
normal conditions. Once the congestion state is over, the normal flow of packets in 
the network resumes. An important QOS metric for a class II connection is thus an 
overload probability, which measures the likelihood of occurrences of the radio 
congestion state. The average duration of the congestion state is another important 
QOS metric for this class. Also important is the QOS metric of a minimum bandwidth 
service probability. This probability measures the percentage of a connection 
duration during which the class II connection is afforded bandwidth more than a 
specified amount. 

Detailed Description Text (24): 

Specifically, processor 501 queries the mobile user as to the type of connections 
required, as indicated at step 503. By way of example, but not limitation, the 
mobile user in this instance requests, say, a type A connection. Processor 201 
records in memory 203 the current numbers of connections of types A, B, and C which 
have been admitted and not yet terminated in cell-cluster 45. At step 505, 
processor 201 retrieves the current numbers of the different connections from 
memory 203. Processor 201 then proceeds to step 507 where it looks up the 
connection table of FIG. 3 and searches for a row which contains the numbers of 
type B and C connections identical to and/or just larger than the respective 
current numbers. Processor 201 then determines at step 509 whether the number of 
type A connections appearing in the row just identified is greater than the current 
number of type A connections. If it is not greater, processor 201 rejects the call 
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request initiated by the mobile user through the associated base station, as 
indicated at step 511. Otherwise, processor 201 proceeds to step 513 where it 
further queries the mobile user as to other requirements such as bandwidth, call 
holding time and hand-off rate requirements. 

Detailed Description Text (25) : 

After collecting the necessary information which forms a call profile of the 
requested connection, processor 201 reviews the local policies of each cell in 
cell-cluster 45, including the sharing and scheduling policies of the different 
call classes in the cell, as indicated at step 515. The sharing and scheduling 
policies may particularize the proportions of the cell bandwidth which need to be 
maintained among the different classes of connections. If upon review the local 
policies are not satisfied, processor 201 returns to step 511 where the call 
request is again rejected. Otherwise, processor 201 grants admission of the 
requested call to the cell where the mobile user is in, and assigns an unused VCI 
to the newly-admitted call for identification, as indicated at step 517. Processor 
201 then sends at step 519 the profile of the new call, along with its VCI, to each 
base station so that the same profile need not be elicited during a future hand- 
off. Finally, at step 521, processor 201 updates memory 203 to reflect the latest 
numbers of the different types of connections in cell-cluster 45. 

Other Reference Publication (11) : 

J. Turner, "Managing Bandwidth in ATM Networks with Bursty Traffic, " IEEE Network, 
pp. 50-57, Sep. 1992. 



CLAIMS : 



5. The system of claim 2 wherein a metric for one of said qualities of service is a 
probability of receiving at least a specified amount of bandwidth during a 
connection lifetime. 



15. The system of claim 12 
a probability of receiving 
connection lifetime. 

25. The method of claim 22 
a probability of receiving 
connection lifetime. 



wherein a metric for one of 
at least a specified amount 

wherein a metric for one of 
at least a specified amount 



said qualities of service is 
of bandwidth during a 

said qualities of service is 
of bandwidth during a 



35. The method of claim 32 wherein a metric for one of said qualities of service is 
a probability of receiving at least a specified amount of bandwidth during a 
connection lifetime. 
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File: USPT 



May 17, 1994 



DOCUMENT-IDENTIFIER: US 5313454 A 

TITLE: Congestion control for cell networks 

Abstract Text (1) : 

A feedback control system for congestion prevention in a cell (packet) switching 
communication network is described. Congestion control is accomplished by 
controlling the transmission rate of bursty traffic in the presence of high 
priority, voice, low speed statistical, high speed deterministic and multicast 
data. Because bursty traffic is relatively insensitive to delay, adequate buffer 
capacity can be provided at the network nodes in order to minimize bursty data cell 
loss. By monitoring the buffer queue lengths at the nodes, a control signal can be 
generated at each intermediate node indicating the state of congestion. Excess 
queue length indicates incipient congestion while short queue lengths indicate 
excess capacity. Queue status is forwarded to the destination node where it is 
interpreted and sent back to the source node as a feedback rate control signal 
using a 2-bit code. The source node regulates the rate of bursty data transmission 
over the cell network in accordance with the feedback control signal thus 
minimizing congestion and concomitant data loss while efficiently utilizing 
available network bandwidth . 

Brief Summary Text (13) : 

Each of these six traffic types are buffered at each network node in accordance 
with their particular sensitivities to network delay and cell loss. Cell loss may 
occur due to intermittent short term overload of network bandwidth and lack of 
adequate buffer capacity. For example, voice traffic is relatively delay sensitive 
and insensitive to occasional cell loss. In contrast, data traffic, such as file 
transfers, is relatively insensitive to delay but is data loss sensitive. High 
priority data is both delay and loss sensitive. To accommodate these differences, 
each class of traffic is typically placed in a preassigned queue, each with a 
different service priority. During periods of network traffic congestion, when 
network traffic demand exceeds the network's bandwidth capacity, servicing 
algorithms are typically employed to discriminate between traffic classes in order 
to allocate bandwidth . Delay is managed by properly sizing the queue depths and 
prioritizing transmission within a class based upon a measure of the time that a 
cell has been in the network as, for example, by use of time stamps and hop counts. 



Brief Summary Text (14) : 

Even with these sophisticated queueing and service algorithms, congestion (due to 
excess arriving traffic) can occur. This congestion is typically divided into three 
categories: short-term, medium-term, and long-term. Short-term congestion, 
typically handled by discarding traffic at the queue, may be done haphazardly or 
preferably selectively by having cells marked with their "discard eligibility". 
Long-term congestion is controlled by admission policies that allocate resources 
( bandwidth and buffers) at the time a connection is established. If no resources 
are available, the connection is not allowed. 

Brief Summary Text (16): 

An example of a general rate regulation scheme for a bursty data source on a per 
virtual connection basis is described in a paper by K. Bala, et al., entitled, 
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Congestion Control for High Speed Packet Switched Networks, published in the 
proceedings of the IEEE INFOCOM Jun. 5-7, 1990, pages 520-526. At the initial 
establishment of a virtual connection, a minimum amount of guaranteed bandwidth is 
allocated. The simplest system described uses the concept of a "leaky bucket" input 
rate controller that uses "tokens" and "spacers" to control the average data rate 
introduced into the packet switched network. Tokens arrive at the controller at a 
fixed rate. Each token corresponds to fixed number of bytes. The controller buffers 
the packet until enough tokens are collected for transmitting the entire packet. 
The token bucket has a fixed maximum capacity corresponding to the maximum packet 
burst duration. Tokens arriving to a full bucket are dropped. Thus, the system can 
handle different length packets which are transmitted without fragmentation. Peak 
rate control is accomplished by means of a spacer that introduces a suitable delay 
proportional to the length of the prior transmitted packet. 

Brief Summary Text (17): 

A given session on a virtual connection may last for long periods of time (up to 
hours) . Bursty data sources are characterized by intermittent high data rate burst 
with significant spans of inactivity between bursts. Under these circumstances, the 
above described simplest system would result in underutilization of the bandwidth 
capacity of the system because of the prescribed safe bandwidth limit assigned to 
the virtual connection session. 

Brief Summary Text (18): 

Average bandwidth utilization efficiency is typically improved by introducing 
"colored" tokens, for example, green and red. Green tokens correspond to packets 
received for transmission that fall within the minimum guaranteed bandwidth 
protocol while the red tokens correspond to packet data received for transmission 
in excess of the guaranteed minimum rate. Intermediate nodes provide per trunk FIFO 
buffer service and use the colors associated with each packet for congestion 
control. In general, green packets are protected and passed along while red packets 
are discarded upon arrival whenever the chosen metric (usually queue lengths) for 
congestion threshold is exceeded. Even though discarding of packets implies 
retransmission of the lost packet data, the system is represented as improving the 
average utilization of bandwidth capacity. 

Brief Summary Text (23) : 

In summary, Ramakrishnan and Jain describe a system using window control at the ISO 
Transport layer using window duration control rather than rate control. Rate 
control is indirectly controlled by the limiting actions of acknowledgements and 
window length. Because transmission rate is a direct measure of bandwidth, better 
short term control of this system resource can be obtained by direct rate control. 

Brief Summary Text (27) : 

One object of the present invention is to optimize the use of available system 
bandwidth . 

Brief Summary Text (29) : 

Another object of the present invention is to provide a dynamic bandwidth (or data 
rate) allocation scheme that allows individual users to use unused network capacity 
for increasing throughput when necessary to accommodate the peak loads of 
individual users . 

Detailed Description Text (3) : 

Each node 22 incorporates a Tl transmitter/receiver that includes the fair queuing 
and servicing circuitry. The Tl transmitter/receivers support six classes of cell 
traffic: high priority (HP), voice, low speed statistical (LSS), high speed 
deterministic (HSD) , bursty, and multicast. As will be discussed in detail below, 
each Tl transmitter/receiver supports the traffic classes via six queues and a 
service routine. The service routine guarantees a minimum amount of bandwidth to 
each class of traffic under normal operation and allocates spare bandwidth 
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according to a predefined priority scheme. 
Detailed Description Text (29) : 

FIG. 5 is an example of a four node network 20 for use in explaining the onset of 
congestion interval to network 20. Assume that a bursty data working connection 
between user A at node 22-A and user CI at 22-C via node 22-B involving FRP 59A1, 
TXR 56A1, TXR 56B1, TXR 56B2, TXR 56C1, and FRP 59C1. Further, assume that user D 
subsequently establishes a working bursty data connection through node B to user C2 
at node 22-C involving FRP 59D1, TXR 56D1, TXR 56B3, TXR 56B2, TXR 56C1, and FRP 
59C2. If either user A or D should increase their transmission rate because of an 
excess available input load, node 22-B could become congested at the common TXR 
56B2 (shown shaded) if the combined bursty data rate exceeds the available capacity 
on trunk 42 connecting nodes 22-B and 22-C. Similarly, congestion could occur in 
the reverse direction at TXR 56B3 of node 22-B interfacing with cell trunk 42 
connecting node 22-B and 22-D if the combined bursty traffic between user C2 and 
node 22-D plus that between, say, user B and node D exceeded the available 
bandwidth between nodes 22-B and 22-D. 

Detailed Description Text (30) : 

FIG. 6 shows the effects of congestion on effective network bandwidth and delay as 
a function of the offered load bandwidth . At low average load rates (Region I), 
throughput increases linearly with load, while delay shows a moderate rate of 
increase with load. When throughput approaches the network's information rate 
capacity, mild congestion results (Region II) as average queue lengths increase. 
Throughput saturates, increasing only slightly with increased offered load, while 
delay exhibits sharp increases. Finally, if the offered load increases some more, 
threshold is exceeded when Region III is reached, causing a breakdown in throughput 
(severe congestion) and hence unlimited delay because of data losses requiring 
constant retransmission. 

Detailed Description Text (31) : 

In order to efficiently use the bandwidth resource of a cell switching network, it 
is desirable that peak offered loads be accommodated by adequate buffering, 
particularly for bursty data which is more tolerant of network delay. Bursty data 
tends to be high -bandwidth short-duration messages that, if uncontrolled, may 
either cause congestion or require that the network operate with a high percentage 
of average unused bandwidth . Ideally, the average offered load would operate at 
point A of FIG. 6, where peak loads would not be likely to cause severe congestion. 



Detailed Description Text (82) : 

Table 1 is an example that details the mapping of service order, j, and spare 
bandwidth priorities, k, for each class of traffic, i, in the preferred embodiment. 
Note that the service priority is according to assigned minimum bandwidth . 

Detailed Description Text (83) : 

The servicing routine uses a credit accrual scheme to ensure that each class of 
traffic receives a selectable minimum bandwidth . In selecting minimum bandwidths 
for each class of traffic, let N denote the total available bandwidth on a cell Tl 
trunk and let T denote the queue server tick interval. The unit of N is not 
relevant; it can be specified as a number of cells per second, or any other 
throughput unit. For a non-fractional Tl trunk N-8000 cells per second. Similarly T 
can be given in any convenient unit of time. For one embodiment of the node, the 
tick interval T equals 125 microseconds. Thus, the product N*T represents the 
capacity of the cell trunk per tick interval, or the quantum of bandwidth . 

Detailed Description Text (84): 

Each class of traffic is assigned a minimum amount of the quantum of bandwidth, 
with the exception of high priority traffic. This is because all high priority 
traffic will be serviced regardless of the required bandwidth . The sum of the 
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minimum class bandwidths must be less than N to allow some bandwidth for high 
priority traffic. In other words, if i represents the class number, and N.sub.i 
represents the minimum bandwidth assigned to the i.sup.th traffic class, then 
N.sub.i +N.sub.2 +N.sub.3 +N.sub.4 +N.sub.5 <N. 

Detailed Description Text (85) : 

Each minimum bandwidth N.sub.i can be transformed into a timer value, D.sub.i, 
representative of the number of tick intervals T that must elapse for traffic class 
i to acquire its quantum of bandwidth . The timer value D.sub.i = ( 1/N . sub . i ) /T . Note 
that D.sub.i may not be an integer value because it represents a ratio of 
bandwidths, i.e., D.sub.i =N/N.sub.i because N*T=1. 

Detailed Description Text (86) : 

Given selected timer values D.sub.i for i=l, 2, 3, 4, 5, a credit accrual routine 
runs simultaneously .with the service routine. Each class of traffic i is assigned a 
timer T.sub.i, which is initialized to the associated timer value, D.sub.i. The 
timer T.sub.i is decremented every T units of time. When the value of timer T.sub.i 
is less than or equal to zero a transmission credit C.sub.i accrues for traffic 
class i. Because of the inverse relationship between N.sub.i and D.sub.i, the 
greater the allocated minimum bandwidth for a class of traffic, the faster the rate 
at which it acquires transmission credit. The presence of a transmission credit 
permits a cell from traffic class i to be serviced. After servicing of class i, 
timer T.sub.i is updated by adding D.sub.i to the previous value of T.sub.i. Using 
this method of accrual, each class of traffic i accrues N.sub.i credit in a tick 
interval of T. 

Detailed Description Text (88) : 

FIG. 14(a) is a flow diagram of the service routine for a single tick interval 
implemented by queue manager 76. Using a credit based strategy for servicing cell 
traffic, queue manager 76 guarantees each class of traffic a minimum bandwidth . 

Detailed Description Text (92) : 

If Q.sub.i or C.sub.i =0, no credit is available for class i or no cell is queued 
for class i, then spare bandwidth results. Consequently, index B, which indicates 
the number of spare bandwidth credits available is incremented in step 416. 

Detailed Description Text (93) : 

Step 418 checks to see if the priority order index, j, has been exhausted, and if 
not, returns to step 406 where index j is incremented. If all values of j have been 
exhausted, step 420 checks to see if B>0, indicating that spare bandwidth is 
available for distribution in accordance with protocol 800 referenced in step 422. 
Otherwise, the process terminates. 

Detailed Description Text (94): 

FIG. 14(b) is a flow diagram for the spare bandwidth allocation process 800 which 
is initiated by setting the spare bandwidth priority index so that k=l. In step 
802, the traffic class index, i, is set equal to the value of k. Step 804 checks 
boolean flag Q.sub.i to see if data is present, and if so, proceeds to step 806 
where the credit, C.sub.i, is checked. If C.sub.i =1, then the i.sup.th class is 
serviced in step 808 and the excess bandwidth index B is decremented in step 810. 
Step 812 checks if any excess bandwidth remains and, if not, the process ends. If 
excess bandwidth is not exhausted, or if Q.sub.i =0 or C.sub.i =0, the process 
moves to step 814 where index k is incremented. Step 816 checks the value of index 
k: if k is less than 3, the process returns to step 802; if 3 . ltoreq. k. ltoreq. 6, 
then the process proceeds to step 818; and if k=6, the process moves to step 822. 

Detailed Description Text (95) : 

If 3 . ltoreq. k<6, then one of three possible and equal priority queues may be 
serviced. In order to ensure fair and equal distribution of excess bandwidth to 
voice (i=3), bursty (i=4), or multicast (i-5) data, steps 818 and 820 service these 



h eb bgeeef 



e g ef 



Record Display Form 



Page 5 of 6 



three round-robin by incrementing index n (mod 3) in step 818 and setting i=3+n in 
step 820. The process then proceeds back to step 804. When the process ends because 
all excess bandwidth has been allocated, index n remains set at its last value. The 
next time that excess bandwidth obtains after class i=l and i=2 have been serviced, 
index n picks up the next round-robin value in step 818. 

Detailed Description Text (96) : 

If the test in step 816 indicates that k=6, all five classes have been serviced. 
Step 822 tests to see if excess bandwidth still exists and if so, repeats the 
sequence by initializing the priority index so that k=l and then proceeds to step 
802. Otherwise, the process ends. 

Detailed Description Text (97) : 

The order of allocating spare bandwidth described causes the impact of heavy high 
priority traffic to be born primarily by bursty data, multicast data and voice 
data. Correspondingly, low-speed statistical data and high speed statistical are 
less affected by periods of heavy high priority data. 

Detailed Description Text (98): 

The described method of allocating spare bandwidth between various traffic classes 
by TXR 56 is an open-loop control system because the data rate is controlled by the 
sending node without any feedback from the cell switching network. This procedure 
leads to a conservative allocation of network resources because each terminal 
network node acts independently and without specific knowledge of the traffic state 
of the network. In order to achieve higher bandwidth utilization by bursty traffic, 
without undo congestion on a given virtual connection, it is necessary to provided 
the ICA feedback information about the level of bursty traffic being handled by all 
FRPs involved with a given virtual connection. 

Detailed Description Text (99): 

ICA is configurable on a per connection basis. The configurable MIR and PIR 
guarantee that each connection gets at least its minimum allocated bandwidth, 
independent of other traffic. 

Detailed Description Text (145) : 

FIG. 16 is a flow diagram that describes the per virtual connection rate (bandwith) 
change process 500 by which data rate changes imposed on cell transmitter 220 are 
adjusted by frame receive controller 201. At step 500, the i.sup.th bursty channel 
bandwidth, Ni, is initialized by setting the transmission rate to the quiescent 
rate, QIR.sub.i. Step 504 checks to see if the queue has been inactive for a period 
of time greater than T.sub.Q, a prescribed configuration parameter. But because the 
channel has just been activated, the process passes on to step 507. Otherwise, it 
would go to step 506 where the quiescent rate, QIR.sub.i, is assigned. If no rate 
change has been received, test step 507 moves the process back to step 504, forming 
a wait loop. If a rate change moves the process to step 508 where it is determined 
if it is a rate increase or decrease. 

Detailed Description Text (148) : 

The credit manager function, resident in cell transmitter 220 determines cell 
receiver 210*3 per channel output rate by assigning credits in accordance with the 
state of congestion and data availability. In the four V.35 port embodiment, each 
channel is serviced round-robin. The relative priority given to each (up to 252) 
virtual connections is determined by the bandwidth assignment algorithm in 
conjunction with the credit manager servicing algorithm as shown in the flow 
diagram of FIG. 17. 

Detailed Description Text (149): 

Step 600 initializes the credit process by setting the ith virtual circuit (VC) 
connection's credit, Ti, equal to Di, where Di=N/Ni or the number of tick 
intervals, T, that must elapse for VC connection i to acquire access to the cell 
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network. Thus, Di is derived from the current value of Ni generated by bandwidth 
assignment process 500. Step 602 sets the VC index i=l . The corresponding ith 
interval, Ti, is decremented by one tick interval, T, in step 604. Test step 606 
checks to see if the resulting value of Ti is equal to or less than zero, 
indicating that a credit should not be added to the i.sup.th credit index, Ci, and 
if so, passes on to step 616, where the round-robin procedure is initiated by 
incrementing index i. Otherwise, step 608 is invoked by crediting (incrementing) 
Ci. Step 610 checks if the incremented value of Ci exceeds the upper limit, Cmax, 
and if so, moves to step 612 where Ci is set equal to Cmax. The process moves on to 
step 614. Step 614 restores a positive non-zero value to Ti by adding Di to the 
value obtained from step 604. (In this manner, non-integer values of Ti are 
accommodated without the loss in precision that would result if Ti were to be 
rounded to the nearest integer value.) Step 616 leads to test step 618 to see if 
all of the VC connections have been served, and if so, a wait of one tick period, 
T, is imposed by step 620 before repeating the process by returning to step 602. 
Otherwise, the process returns to step 604. 

Detailed Description Paragraph Table (1) : 

TABLE 1 Class Spare Traffic Number Service 

Bandwidth Name i Order*, j Priority, k High 

Priority 0 First X High Speed 1*1 Deterministic Low Speed 2*2 Statistical Voice 
3 * (3)** Bursty 4 * (4)** Multicast 5 * (5)** 

*Service order determined by minimum 

configured bandwidth. **Spare bandwidth priority for classes i = 3, 4, and 5 are 
equal . 



h eb bgeeef 



eg e f 



